1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, and computer program product that enables software objects and applications to dynamically self-propagate, as needed, through a computer network.
2. Description of the Related Art
Business and consumer use of distributed computing, also commonly referred to as network computing, has gained tremendous popularity in recent years. In this computing model, the data and/or programs to be used to perform a particular computing task typically reside on (i.e. are xe2x80x9cdistributedxe2x80x9d among) more than one computer, where these multiple computers are connected by a network of some type. The Internet, and the part of the Internet known as the World Wide Web (hereinafter, xe2x80x9cWebxe2x80x9d), are well-known examples of this type of environment wherein the multiple computers are connected using a public network. Other types of network environments in which distributed computing may be used include intranets, which are typically private networks accessible to a restricted set of users (such as employees of a corporation), and extranets (e.g., a corporate network which is accessible to other users than just the employees of the company which owns and/or manages the network, such as the company""s business partners).
The client/server model is the most commonly-used computing model in today""s distributed computing environments. In this model, a computing device operating in a client role requests some service from another computing device operating in a server role. The software operating at one particular client device may make use of applications and data that are stored on one or more server computers which are located literally anywhere in the world. Similarly, an application program operating at a server may provide services to clients which are located throughout the world. A common example of client/server computing is use of a Web browser, which functions in the client role, to send requests for Web pages or Web documents to a Web server. Another popular model for network computing is known as the xe2x80x9cpeer-to-peerxe2x80x9d model, where the requester of information and the provider of that information (i.e. the responder) operate as peers.
Whereas the HyperText Transport Protocol (HTTP) is the communications protocol typically used for communication between a client and a server in a client/server model, a protocol such as Advanced Program-to-Program Communication (APPC) developed by the IBM Corporation is typically used for communication in a peer-to-peer model.
Distributed computing provides a number of advantages which are well known and need not be described herein. However, there are shortcomings in the way that the computer systems exchange data in these prior art distributed computing techniques. In particular, the prior art requires that processing code is designed and implemented in pairs: one part for executing the client (or requester) functionality, and the other part for executing the server (or responder) functionality.
An example of the requirement for paired applications can be seen in the case where a Web page is to include an image file. Suppose the image is originally created, by the first of the two application xe2x80x9cpartsxe2x80x9d (i.e. a creation part), as a file in the JPEG format. When a Web page which includes the image as an embedded JPEG image file is generated at a server and transmitted to a client for rendering, the client device must have the other xe2x80x9cpartxe2x80x9d of the JPEG software (i.e. a rendering part) locally available in order to process the image for rendering at the client device. If the client does not have the proper software for processing (i.e. rendering) the received image file, then either the software must be obtained or the image cannot be rendered. Most users of distributed computing will be familiar with the frustration of a scenario of this type, where a file is received for which the local processing xe2x80x9cpartxe2x80x9d is unavailable. In many cases, the user will not be able to determine where to obtain the missing partxe2x80x94or even what the missing part is.
Another common situation where the requirement for paired software becomes apparent is when a client device receives a xe2x80x9cPDFxe2x80x9d, or Portable Document Format, file. A product such as Adobe Acrobat is typically used to create files of this type; a product such as Adobe Acrobat Reader is then used to view the file. By convention, application software that transmits a PDF file typically provides a message to the user containing information on how to obtain a copy of the Reader software if it is not already locally available on the user""s computing device. However, the user must then take explicit action to obtain the Reader software, and becomes responsible for installing, configuring, and maintaining the software on his or her device.
While the examples provided above occur most frequently in a Web environment, this is merely for purposes of illustration: paired applications of one type or another exist whenever one computing device provides data or processing services for other device(s). For example, a book supply company may allow its customers to place orders electronically through its extranet, perhaps using a proprietary communications protocol. In this scenario, the customers"" computing devices must have the software part installed which properly formats and transmits order requests, and the company""s server(s) must have the software part installed which receives those requests and uses the information contained therein to complete the book ordering process. Only devices on which the customer""s part of the application is installed are able to participate as customers of the book supply company.
Many more examples of paired applications will be obvious to one of skill in the art.
In the general case, the two parts of a paired application will execute on different physical computing devices. Each of the two parts thus needs to be explicitly distributed to each target device on which it is to operate, and must be installed on that device as well. If these processes have not been performed at a particular target device, then the application""s functionality cannot be used at that device. If the software is subsequently revised, then the distribution and installation process must be repeated. Furthermore, once the software has been installed on a device, maintaining the software (for example, ensuring that the most recent version is available, and ensuring that obsolete or infrequently-used software does not waste storage space on the local device) typically becomes the responsibility of the device owner, who may or may not be capable of performing the necessary maintenance tasks. As will be obvious, when one or both of the parts of a paired application is to reside on a large number of devices, this prior art methodology results in a huge administrative burden that is expensive, time-consuming, and error-prone.
Applets provide one prior art technique for dynamically delivering application code to a target machine. However, this technique does not enable downloading data objects and code segments as part of an integrated application, and has several limitations which make it unsuitable as a general solution for distributing code in an application-independent manner. First, the well-known xe2x80x9cJava sandboxxe2x80x9d restriction, which is designed to prevent security problems when applets are downloaded, narrowly restricts the location of the code that can be executed. In particular, the class loader which downloads applets loads them into a namespace hierarchy that identifies the server and codebase which was the source of the download. When an applet executes, it is automatically restricted to interacting with server code on the source server, and within the corresponding codebase. The sandbox restriction also requires that a static data area is allocated for use by the code in the applet""s namespace. For example, objects to be used by the classes (such as values for variables) are stored in this static data. If multiple requests for an applet are serviced from different servers and/or codebases, a separate and redundant instance of the code for each applet will be created, each of which must use a separate static data area.
Second, applets are downloaded in a xe2x80x9cpullxe2x80x9d mode using a synchronous communication model, meaning that the initiator (such as a requesting client browser) receives the code for execution in response to a request for delivery of the applet code to a single destination machine. There is no technique known to the inventors for asynchronously delivering code as applets using a xe2x80x9cpushxe2x80x9d model (meaning that the initiator delegates the execution to another system). Third, the downloaded code is loaded into the browser""s storage space, which limits accessibility to the code and requires allocation of static data areas, as stated above. There are no inherent mechanisms for enabling applets to automatically take advantage of cached data, and no management or system controls for automatically reclaiming the space used by an applet after a life-span of the code has been exceeded.
In addition, the applet model does not provide a technique for flexible and granular retrieval of objects and individual code segments, as part of an integrated distributed application. Furthermore, it may be desirable to offload part of a paired application for execution at a device other than the requesting client to which an applet must be loaded, in effect providing a xe2x80x9cmirroringxe2x80x9d site that may be used to balance the workload in a distributed environment: this is not possible given the inherent restrictions on which the applet model is designed. In addition, when a Web interface to legacy applications and data is to be provided through a Web browser, client code to provide access to the back-end legacy code and data cannot be downloaded for execution on a Web client using the applet approach due to the sandbox restriction.
Channel technology is another prior art technique for delivering code to a target machine. This technology does use a subscription model, but suffers from most of the disadvantages which have been described with reference to applets. For example, the subscriber""s computer needs to pull periodically from the publisher""s computer for updates. This is not as dynamic and efficient as if the publisher""s computer can xe2x80x9cpushxe2x80x9d the updates out to the subscriber automatically.
Thus, no suitable technique is known to the inventors for automatically and asynchronously transmitting data and the processing code of the parts of paired applications from one system to another in an application-independent manner.
Accordingly, what is needed is an improved technique for distributing software among computer systems in a distributed computing environment.
An object of the present invention is to provide an improved technique for distributing software among computer systems in a distributed computing environment.
Another object of the present invention is to provide this technique whereby the objects and/or software application code to be used in a distributed computing environment propagate, in an application-independent manner, to devices which need to use those objects and/or software application code.
Yet another object of the present invention is to provide a technique whereby a software application which sends a request to another process identifies, as part of the request, the objects and/or code needed to carry out the request.
Still another object of the present invention is to provide this technique whereby a software application which receives a request from another process automatically identifies, from the request itself the objects and/or code needed to carry out the request, and automatically obtains any objects and/or code which are not already locally available.
Another object of the present invention is to provide a technique for software which receives a response message to automatically identify, within the response, the data and code required for processing the response, thereby enabling object and code propagation to occur in a symmetric manner.
A further object of the present invention is to provide a technique for programmatically controlling the life-span of the automatically obtained objects and/or code.
Another object of the present invention is to provide a technique for facilitating business-to-business (and business-to-consumer) electronic commerce, whereby the software needed for an electronic transaction automatically propagates among the devices of the parties to the transaction in an application-independent manner.
Yet another object of the present invention is to provide a technique that facilitates dynamic offloading of work among computing systems by automatically propagating the required data and processing code to a device which is to perform the offloaded work.
Still another object of the present invention is to provide a technique wherein the propagated code operates to access legacy host data and applications.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for enabling software objects and applications to dynamically propagate through a computer network as needed, comprising: creating, by a requester, a request parcel comprising input data for processing a request and an identification and location information of one or more first code segments required for processing the input data; sending the request parcel to a receiver over the computing network; receiving the sent request parcel at the receiver; determining whether the identified first code segments in the received request parcel are locally available to the receiver, and for obtaining them using the location information in the request parcel if not, so that they become locally available; processing the request using the input data and the locally available first code segments, thereby creating a response; creating a response parcel comprising output data for the response and an identification and location information of zero or more second code segments required for processing the output data; sending the response parcel to the requester over the computing network; receiving the sent response parcel at the requester; determining whether the identified second code segments in the received response parcel, if any, are locally available to the requester, and for obtaining them using the location information in the response parcel if not, so that they become locally available; and processing the response using the output data and, when specified in the response parcel, the locally available second code segments.
The sending of the request and response parcels and the receiving of the request and response parcels preferably uses a message queuing system.
The request parcel and the response parcel may be specified using a markup language, which is preferably the Extensible Markup Language (XML).
Each of the request parcel and the response parcel may further comprise an identification and location information for one or more software objects which are to be stored at the receiver and the requester, respectively. In this case, the technique further comprises determining whether the identified software objects are locally stored and for obtaining them using the location information if not.
The request parcel may comprise a plurality of processing requests and the response parcel may comprise a plurality of processing responses. In this case, each processing request and processing response specifies an identifier which enables correlating a particular processing request with its associated processing response. Either or both of the request parcel and response parcel specify a life span for the identified first and second code segments: In this case, the technique further comprises removing the identified first code segments from local storage of the receiver when the life span of the first code segments is exceeded, and removing the identified second code segments from local storage of the requester when the life span of the second code segments is exceeded.
The technique may further comprise: comparing, when the determination of whether the first code segments are locally available has a positive result, whether a first resource version specified in the request parcel indicates that the locally available first code segments must be reloaded, and reloading them using the location information in the request parcel if so; and comparing, when the determination of whether the second code segments are locally available also has a positive result, whether a second resource version specified in the response parcel indicates that the locally available second code segments must be reloaded, and reloading them using the location information in the response parcel if so.
A mirroring site may be dynamically established, to which processing of work elements may be offloaded from another site. In this case, the request in the request parcel may be a refresh request for a read-access object, an update request for performing an update of a stored object, etc.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.